The present invention relates to a method for determining the access privileges currently held by a database user with respect to objects in the database. More particularly, the present invention relates to a product-independent method for automatically determining such privileges and for displaying (1) the names of the objects to which the user has access privileges, (2) an identification of the type of access to each object to which the user has access privileges, (3) an identity of the associated access group through which the user has access privileges and (4) an indication as to whether or not such access privileges may be extended to others.
It is currently quite difficult for a database user to determine those objects to which he or she has access privileges. A given user may have "direct access" to a database object, for example by virtue of having created the database object or, "indirect access" to the database object by virtue of membership in a group or class which has access to that object. As a special case of this category, a database user always has access to those database objects which are generally accessible.
As used herein, the term "access privileges" is intended to mean any type of access to a database object. Such access may include, by way of example and not limitation, the ability to view an object; to modify an object, e.g., by changing numbers in a table; to alter an object, e.g., by changing the object's structure; and to delete all or part of an object. The formal types of access privileges have been standardized in different database management systems and are well known to those skilled in the art.
The term "direct access" is intended to include those types of access privileges which a user has without reference to a group or class. These privileges are typically granted directly to a user by the owner of the object to be accessed or by a specially privileged administrator.
The term "indirect access" includes all types of access which are not direct. Public access is a type of "indirect access" as is access through membership in a defined group or class. For example, the personnel department in a corporation may be granted access to certain database objects (e.g., confidential personnel files) to which no one else in the corporation has access. Corporate employees who join and later leave the personnel department will be members of this group during their tenure, and will thus have temporary access to the personnel files.
Groups are therefore "pseudo entities" with prescribed access privileges to certain database objects. These groups are treated in the database as if they were actual users.
A given database user may be a member of several groups within an organization. For example, the Director of Personnel may be a member of the personnel group, as well as a member of a high level management group within the corporation. It is not unusual, therefore, for a database user to be unaware or uncertain of all the groups to which he or she belongs for purposes of access within a database. Since the grouping itself is normally stored outside the database, the user may not even have access to information about all the possible groups and to the access privileges of each group.
Consequently, it is extremely difficult for a user to determine all of the database objects to which he or she has access privileges. A given user would probably know those database objects which he or she created and owns, but perhaps not if these objects were numerous or were created over a long period of time. A user may also be aware that he or she is a member of at least one group; however, he or she may not know all of the groups to which he or she belongs, not to mention the access privileges of all such groups.
Currently, therefore, a user would find it difficult, if not impossible to determine and display all of those objects to which he or she has access privleges, together with the types of privileges for those objects.
All of the information required by a user to determine his or her access privileges is, in fact, available somewhere in the system. However, to obtain this information the user must submit a number of queries against the system catalogues as well as against the database itself. Some of the necessary information, such as the effect of security group membership, is not normally available without a security code.
Used throughout the specification are a number of additional terms that require definition. These definitions are set forth below:
A database "object" is a set of data within a database which is arranged in a particular way. For example, this set of data may be a "table" or a "view".
A "table" is a set of data arranged in rows and columns.
A "view" is a logical subset of an object which is accessible to a user. For example, a view of a table may contain all the rows of the table except one.
A "collection" is a set of objects within a database. These objects may, for example, relate to a common subject.
A "package" is a set of pre-processed commands that can be run against a database.
An "index" is an underlying object within an object. An index to a table forms part of the table.
A "snapshot" is a copy of a table or view at a specific moment in time. For example, a snapshot may be taken of a table once per day, although the current table is continuously changing.
An "rdb" is an acronym for "relational database".
An "alias" is a nickname for an object in the database. For example, the official name of a table may be "2734.5" which is difficult for a user to remember. The user may therefore give the table an alias such as "mytab".
At the present time the OS/2 Query Manager (QM) requires that access privilege determination be available for tables and views in the ASP-1 time frame. To do this, QM presents database users with menus of tables from which they may select. The IBM Common User Access (CUA) specifications require that these menus display only tables which the user may access. This guideline is derived from industry and international standards and is a response to recent human engineering studies. Currently, QM obtains this information from special function calls which work only for OS/2.